Technical Field
This disclosure relates generally to web application security.
Background of the Related Art
Ensuring that modern software systems are free of security vulnerabilities is a daunting task. Such systems often comprise large amounts of code, including third party and remote components. Moreover, the measures that need to be taken to prevent potential attacks, in most cases, are far from straightforward, as they depend on the state of the application, the exact content of the (potentially malicious) data being processed, and the use(s) the application is about to make of that data. The problem is aggravated when it comes to web applications, which by design often feed on untrusted data in the form of user input. Also, web applications often make access to security-sensitive resources, such as databases, file systems or sockets. The problem of securing web applications against malicious attacks therefore has received significant attention.
Cross-Site Scripting (XSS), also known as script injection, is a web application vulnerability that allows malicious users to inject code into pages that are viewed by other users. The most severe consequences of XSS issues are that attacker is able to make a legitimate user's browser perform operations that change application state on behalf of that user, or that make a user's browser disclose private data. Typically, cross site scripting attacks attempt to access cookies that the web application uses to implement security features. Cross site scripts, however, also may compromise security in other ways including, without limitation, tricking the user into supplying credentials to the attacker, causing a denial of service type of attack designed to hinder the server (e.g., loops to send emails, loops posting to a forum, or the like), causing a denial of service type of attack designed to hinder the client (e.g., purposefully implementing an infinite client-side processing loop), and delivering security cookies via web application rather than over secure connection.
Another type of malicious website exploit is Cross-Site Request Forgery (CSRF), whereby unauthorized commands are transmitted from a user that the website trusts. CSRF exploits sessions that are maintained for an authenticated user between a web server and a web client. While XSS exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's web client and web browser.
Solutions to guard against CSRF attacks are known but not ideal because the security controls that are implemented to address the exploit typically disrupt normal operations of the site, as well as the web clients that use that site. For example, in one approach, a CSRF filter is used to inject (in an HTTP response) scripts and a verifiable session identifier so that the web client can present the identifier in a subsequent HTTP request; the web server can then use that identifier to validate its trust of a user and his/her web client. A malicious site that exploits the trust (and that may try to trick the user to submit an unauthorized command to the web server) will not have the verifiable identifier. While web browsers typically support this method, other types of web clients (e.g., REST-based, CLI-based) do not because they lack the necessary support, e.g., the ability to propagate the verifiable session identifier. Products that use REST/CLI interfaces have not been upgraded to support this solution given that CSRF is considered only a medium severity vulnerability of its class.
Another method to mitigate CSRF vulnerability is for the server to reject HTTP requests that originate via an intermediate site. Web browsers set an HTTP Referer attribute (in HTTP headers) to indicate access via an intermediate site. While this method could be implemented by a broader set of web clients, the basic notion of just rejecting HTTP requests that have referrer attributes is likely to break web site normal operations. In particular, a common web site user login approach is to leverage HTTP redirect. When the user accesses a web site without security credentials, the web site typically redirects the user's web browser to authenticate first, and then redirect back to the original web resource. During this process, the web browser will set the referrer attribute during HTTP redirect. Likewise, in more advanced web authentication and Single Sign-On (SSO) implementations, the redirect happens across multiple web sites and requires multiple HTTP requests. Thus, simply rejecting all requests that have referrer attributes breaks web client authentication and SSO.
Other approaches attempt to address the CSRF vulnerability by recommending best practices that attempt to reduce the likelihood of attacks. These include reducing session expiration time, minimizing privileges granted to users, or the like.
Still another approach is to require the client to provide authentication data in the same HTTP request used to perform any operation with security implications. Thus, this method attempts to resolve the problem in effect by not using a session. This is not a practical solution, as users rarely perform just a single critical operation. Indeed, disabling the session and requiring the user to authenticate repeatedly for each request simply defeats the purpose of having trust between the web site and the web client.
Yet another method to prevent CSRF is to require a secret, user specific token in all form submissions and side-effect URLs. This method, however, requires the web client to have additional logic and, thus, it has a high implementation cost. One other method to address CSRF is to verify that the HTTP request header contains certain information, or checking the HTTP Referer header and/or HTTP Origin header. These protections, however, have been proven insecure under a combination of browser plug-ins and redirects, which can allow an attacker to provide custom HTTP headers on a request to any website, hence allowing a forged request.
There remains a long-felt need to provide a reliable and cost-effective method to address the CSRF vulnerability.